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Abstract 


A  major  acquisition  challenge  for  a  program  where  computer  software  is  a  critical  element  of  the 
system  is  the  upfront  determination  of  an  appropriate  licensing  rights  strategy.  This  report  de¬ 
scribes  standard  noncommercial  software  licensing  alternatives  as  defined  by  U.S.  government 
and  Department  of  Defense  (DoD)  regulations.  It  also  suggests  an  approach  for  objectively  identi¬ 
fying  agency  needs  for  license  rights  and  the  appropriate  license  type  for  systems  with  noncom¬ 
mercial  computer  software  or  as  standalone  software  in  the  DoD  environment.  There  are  three 
standard  license  types  for  noncommercial  computer  software:  Unlimited,  Government  Purpose, 
and  Restricted.  Each  of  these  license  types  for  noncommercial  computer  software  conveys  differ¬ 
ent  rights  to  the  agency.  This  report  presents  distinguishing  characteristics  of  the  three  standard 
license  types,  a  method  to  develop  the  supporting  rationale  or  traceability  for  DoD  agency  needs, 
a  high-level  description  of  circumstances  that  fall  outside  of  standard  license  types,  and  a  discus¬ 
sion  of  the  importance  of  deliverables  as  necessary  components  for  implementing  license  rights. 
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1  Introduction 


A  major  acquisition  challenge  for  a  program  where  computer  software  is  a  critical  element  of  the 
system  is  the  upfront  determination  of  an  appropriate  licensing  rights  strategy.  Making  a  decision 
on  licensing  strategy  is  a  U.S.  Department  of  Defense  (DoD)  acquisition  activity  that  requires  a 
forward-looking  approach.  It  also  requires  an  understanding  of  intellectual  property  ownership, 
knowledge  of  the  computer  software  license  types  and  the  rights  each  of  them  grants,  and  ex¬ 
pected  DoD  agency  needs  for  systems  with  noncommercial  computer  software  or  as  a  standalone 
application  throughout  the  entire  product  life  cycle.  This  report  provides  information  about  stan¬ 
dard  licensing  alternatives  that  are  available  for  noncommercial  computer  software  rights  as  de¬ 
fined  by  U.S.  Government  and  DoD  regulations.  It  also  suggests  an  approach  for  objectively  iden¬ 
tifying  agency  needs  for  license  rights  and  the  appropriate  license  type  for  systems  with 
noncommercial  computer  software  or  as  standalone  software  applications  in  the  DoD  environ¬ 
ment. 

There  are  two  general  categories  for  software  referenced  in  Defense  Federal  Regulation  Acquisi¬ 
tion  Supplement  (DFARS) — commercial  and  noncommercial.  “Commercial  computer  software” 
means  software  developed  or  regularly  used  for  non-governmental  purposes  which  (1)  has  been 
sold,  leased,  or  licensed  to  the  public;  (2)  has  been  offered  for  sale,  lease,  or  license  to  the  public; 
or  (3)  has  not  been  offered,  sold,  leased,  or  licensed  to  the  public  but  will  be  available  for  com¬ 
mercial  sale,  lease,  or  license  in  time  to  satisfy  the  delivery  requirements  of  this  contract  [DFARS 
252.227.7014  (a)  (1)  2011].  Commercial  software  could  be  open  source,  freeware,  or  proprietary 
off-the-shelf  software.  “Noncommercial  computer  software”  means  software  that  does  not  qualify 
as  commercial  computer  software  under  paragraph  (a)  (1)  of  this  clause  defined  above  [DFARS 
252.227-7014  (a)  (14)  2011].  In  other  words,  noncommercial  computer  software  has  not  been  li¬ 
censed  or  offered  for  license  to  the  public. 

While  commercial  software  provides  the  government  with  the  same  licenses  as  those  customarily 
provided  to  the  public,  noncommercial  computer  software  does  not  have  a  public  license  by  defi¬ 
nition.  There  are  three  standard  license  types  for  noncommercial  computer  software — Unlimited, 
Govermnent  Purpose,  and  Restricted.  Each  of  these  license  types  conveys  different  rights  to  the 
agency  that  is  acquiring  the  noncommercial  computer  software.  For  those  instances  where  the 
govermnent  and  the  acquirer  cannot  agree  on  licensing  terms  as  conveyed  by  a  standard  license,  a 
license  with  Specifically  Negotiated  Rights  can  be  negotiated.  This  type  of  agreement  is  not  one 
of  the  three  standard  types  because  it  varies  based  on  negotiations.  The  DFARS  notes  that  this  is 
unusual  [DFARS  227.7203-5  2011]. 

In  addition  to  providing  licensing  information  for  noncommercial  computer  software,  the  objec¬ 
tives  of  this  report  are  to 

1 .  present  four  initial  questions  and  develop  a  matrix  to  display  the  distinguishing  characte¬ 
ristics  of  the  three  standard  license  types 

2.  demonstrate  a  method  to  develop  the  supporting  rationale  or  traceability  for  DoD  agency 
needs  and  elaborate  by  focusing  on  needs  related  to  Scope  of  Use 
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3.  provide  a  high  level  description  of  circumstances  that  fall  outside  of  standard  license 
types 

4.  describe  the  importance  of  deliverables  such  as  source  code,  test  environments,  or  other 
tools  that  may  be  necessary  to  use  the  license  rights  that  have  been  granted 

This  report  does  not  provide  a  comprehensive  treatment  of  all  legal  and  contractual  information 
related  to  license  rights  for  noncommercial  computer  software  and  should  not  be  construed  as  an 
authoritative  legal  reference.  Rather,  it  provides  considerations  for  program  managers  (PMs)  and 
other  technical  staff  who  must  ensure  development  and  maintenance  of  noncommercial  computer 
software  for  systems  or  as  standalone  applications.  The  Army  Strategic  Software  Improvement 
Program  (ASSIP)  funded  development  of  this  report,  which  supports  definition  and  communica¬ 
tion  of  the  software  engineering  and  management  events  and  deliverables  necessary  to  be  in¬ 
cluded  in  the  request  for  proposal  (RFP)  for  software-reliant  systems. 1 

For  more  detailed  information  about  DoD  regulations  and  contract  clauses  concerning  rights  to 
computer  software,  refer  to  the  DFARS  Part  227  -  Patents,  Data,  and  Copyrights,  Subpart  227.72  - 
Rights  to  Noncommercial  Computer  Software  and  Computer  Software  Documentation;  and 
DFARS  Part  252  -  Solicitation  Provisions  and  Contract  Clauses,  Section  252.227.  Contracting 
officers  and  legal  resources  can  provide  invaluable  and  more  detailed  information  on  interpreta¬ 
tion  and  negotiations. 


i  ASSIP  is  a  long-term  partnership  among  the  Assistant  Secretary  of  the  Army  (Acquisition,  Logistics,  and  Technology)  (ASA(ALT));  the  Army’s 
Program  Executive  Officers  (PEOs)  and  the  Software  Engineering  Institute  (SEI)  to  dramatically  improve  the  acquisition  of  software-intensive 
systems.  The  Army’s  Software  Engineering  Centers  (SECs),  Training  and  Doctrine  Command  (TRADOC),  Army  Test  and  Evaluation  Com¬ 
mand  (ATEC),  and  the  Army  CIO-G6  also  participate  in  ASSIP.  The  ASSIP  is  focused  on  acquisition  programs,  people,  produc¬ 
tion/sustainment,  and  institutionalizing  continuous  improvement. 
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2  Core  Principles  of  Noncommercial  Computer  Software 
Ownership  and  Licensing 


DoD  does  not  “own  ”  the  technical  data  and  computer  software  included  in  deliverables,  even  if 
the  Department  paid  for  100  percent  of  the  development  costs  [OUSD  AT&L  2001], 


2.1  Why  You  Need  a  License  for  Noncommercial  Computer  Software 

Current  U.S.  law  considers  computer  software  to  be  intellectual  property  (IP) — property  (as  an 
idea,  invention,  or  process)  that  derives  from  the  work  of  the  mind  or  intellect — and  subject  to 
copyright  protection.  Under  U.S.  law,  the  author  of  a  work  is  automatically  the  owner  of  the  copy¬ 
right  in  the  work.  If  an  employee  creates  a  work  as  part  of  his  civilian  employment,  the  civilian 
employer  is  the  “author”  for  copyright  purposes  [Friedman  1997]. 

This  “work  for  hire”  concept  has  led  many  government  managers  to  assume  that  noncommercial 
computer  software  that  the  government  funds  and  contractors  produce  under  contract  is  govern¬ 
ment  property.  However,  the  government  does  not  own  the  noncommercial  computer  software 
even  if  it  paid  for  100  percent  of  the  development  cost  [OUSD  AT&L  2001].  DoD  has  established 
specific  regulations  concerning  noncommercial  computer  software  that  provide  “rights  to  use” 
while  preserving  the  original  developer’s  ownership  of  the  intellectual  property.  The  purpose  of 
these  regulations  is  to  support  wider  markets  and  profits  for  developers,  thus  minimizing  DoD’s 
portion  of  development  costs. 

Instead  of  receiving  ownership,  the  government  obtains  a  license  that  conveys  a  scope  of  rights.  In 
the  case  of  commercial  software,  those  rights  are  the  same  as  those  generally  available  to  the  pub¬ 
lic.  However,  DFARS  defines  multiple  license  types  for  noncommercial  computer  software  for 
systems  or  as  standalone  applications  that  DoD  acquires;  and  each  license  type  conveys  varying 
levels  of  rights  to  the  government.  This  report  focuses  on  the  licensing  rights  for  noncommercial 
computer  software  because  of  the  complexities  that  must  be  considered  to  determine  the  best  li¬ 
censing  decision  and  the  longer  impact  on  cost,  sustaimnent,  and  capabilities. 

DoD  policy  for  noncommercial  computer  software  is  “to  acquire  only  the  computer  software  and 
computer  software  documentation  and  the  rights  in  such  software  or  documentation,  necessary  to 
satisfy  DoD  agency  needs”  [DFARS  227.7203-1  2011],  Selection  of  the  appropriate  licensing 
strategy  requires  sifting  through  a  very  large  haystack  of  needs  and  requirements.  The  needle  you 
are  looking  for  in  that  haystack  is  the  appropriate  noncommercial  computer  software  licensing 
strategy  to  meet  the  changing  DoD  agency  needs  and  expectations  that  could  occur  throughout  the 
product  life  cycle. 

2.2  When  and  Why  You  Need  a  Noncommercial  Computer  Software  License  Strategy 

Operationally,  understanding  DoD  agency  needs  and  the  impact  of  available  license  types  requires 
a  careful  plan  or  method  (i.e.,  a  strategy).  The  DoD  agency  must  complete  this  daunting  exercise 
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of  determining  agency  needs  across  the  whole  product  life  cycle  prior  to  release  of  the  solicita¬ 
tion.  For  the  DoD  community,  the  licensing  strategy  for  noncommercial  computer  software  is  part 
of  the  Data  Management  Strategy  (DMS).  The  DMS  is  included  in  the  Acquisition  Strategy, 
which  must  be  completed  prior  to  the  solicitation.  “DFARS  requires  major  programs  to  develop  a 
long-term  strategy  integrating  data  requirements  across  all  functional  disciplines,  to  include  logis¬ 
tics.  While  the  title  is  Data  Management  Strategy,  the  content  should  include  the  approach  to 
managing  intellectual  property  issues  relating  to  any  computer  software  as  well”  [DAU  2009]. 

Based  on  this  strategy,  the  responding  contractor  will  provide  a  list  of  all  noncommercial  comput¬ 
er  software  products  that  have  restrictions  as  part  of  the  proposal  and  prior  to  award  of  a  contract. 
Regarding  proprietary  assertions,  “there  is  no  DFARS  provision  for  contractors,  after  contract 
award,  to  withhold  data  deliverables  required  by  contract  by  asserting  they  are  proprietary.  The 
only  mechanism  is  to  list  such  items  on  the  assertions  list  and  then  properly  mark  in  accordance 
with  the  DFARS  when  submitted”  [DAU  2009], 

2.3  Noncommercial  Computer  Software  Licenses  and  Associated  Rights  You  Can 
Obtain 

Each  of  the  three  standard  types  of  noncommercial  software  licenses  -  unlimited,  government 
purpose,  or  restricted  -  grants  a  scope  of  rights  to  the  government.  The  following  quoted  informa¬ 
tion  from  DFARS  describes  the  license  rights  that  are  granted  to  the  government  under  each  stan¬ 
dard  noncommercial  license  type. 

“DFARS  252.227-7014  -  Rights  in  Noncommercial  Computer  Software  and  Noncommercial  Computer 
Software  Documentation. 

(b)  Rights  in  computer  software  or  computer  software  documentation.  The  Contractor  grants  or  shall 
obtain  for  the  Government  the  following  royalty  free,  world-wide,  nonexclusive,  irrevocable  license 
rights  in  noncommercial  computer  software  or  computer  software  documentation.  All  rights  not  granted 
to  the  Government  are  retained  by  the  Contractor. 

(1)  Unlimited  rights.  The  Government  shall  have  unlimited  rights  in — 

(i)  Computer  software  developed  exclusively  with  Government  funds; 

(ii)  Computer  software  documentation  required  to  be  delivered  under  this  contract; 

(iii)  Corrections  or  changes  to  computer  software  or  computer  software  documentation  fur¬ 
nished  to  the  Contractor  by  the  Government; 

(iv)  Computer  software  or  computer  software  documentation  that  is  otherwise  publicly 
available  or  has  been  released  or  disclosed  by  the  Contractor  or  subcontractor  without  restric¬ 
tion  on  further  use,  release  or  disclosure,  other  than  a  release  or  disclosure  resulting  from  the 
sale,  transfer,  or  other  assignment  of  interest  in  the  software  to  another  party  or  the  sale  or 
transfer  of  some  or  all  of  a  business  entity  or  its  assets  to  another  party; 

(v)  Computer  software  or  computer  software  documentation  obtained  with  unlimited  rights 
under  another  Government  contract  or  as  a  result  of  negotiations;  or 
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(vi)  Computer  software  or  computer  software  documentation  furnished  to  the  Government, 
under  this  or  any  other  Government  contract  or  subcontract  thereunder  with — 

(A)  Restricted  rights  in  computer  software,  limited  rights  in  technical  data,  or  govern¬ 
ment  purpose  license  rights  and  the  restrictive  conditions  have  expired;  or 

(B)  Government  purpose  rights  and  the  Contractor's  exclusive  right  to  use  such  soft¬ 
ware  or  documentation  for  commercial  purposes  have  expired. 

(2)  Government  purpose  rights. 

(i)  Except  as  provided  in  paragraph  (b)  (1)  of  this  clause,  the  Government  shall  have  govern¬ 
ment  purpose  rights  in  computer  software  developed  with  mixed  funding. 

(ii)  Government  purpose  rights  shall  remain  in  effect  for  a  period  of  five  years  unless  a  differ¬ 
ent  period  has  been  negotiated.  Upon  expiration  of  the  five-year  or  other  negotiated  period, 
the  Government  shall  have  unlimited  rights  in  the  computer  software  or  computer  software 
documentation.  The  government  purpose  rights  period  shall  commence  upon  execution  of  the 
contract,  subcontract,  letter  contract  (or  similar  contractual  instrument),  contract  modification, 
or  option  exercise  that  required  development  of  the  computer  software. 

(iii)  The  Government  shall  not  release  or  disclose  computer  software  in  which  it  has  govern¬ 
ment  purpose  rights  to  any  other  person  unless — 

(A)  Prior  to  release  or  disclosure,  the  intended  recipient  is  subject  to  the  use  and  non¬ 
disclosure  agreement  at  DEARS  227.7103-7;  or 

(B)  The  recipient  is  a  Government  contractor  receiving  access  to  the  software  or  do¬ 
cumentation  for  performance  of  a  Government  contract  that  contains  the  clause  at 
DEARS  252.227-7025,  Limitations  on  the  Use  or  Disclosure  of  Government  Furnished 
Information  Marked  with  Restrictive  Legends. 

(3)  Restricted  rights. 

(i)  The  Government  shall  have  restricted  rights  in  noncommercial  computer  software  re¬ 
quired  to  be  delivered  or  otherwise  provided  to  the  Government  under  this  contract  that  were 
developed  exclusively  at  private  expense. 

(ii)  The  Contractor,  its  subcontractors,  or  suppliers  are  not  required  to  provide  the  Govern¬ 
ment  additional  rights  in  noncommercial  computer  software  delivered  or  otherwise  provided 
to  the  Government  with  restricted  rights.  However,  if  the  Government  desires  to  obtain  addi¬ 
tional  rights  in  such  software,  the  Contractor  agrees  to  promptly  enter  into  negotiations  with 
the  Contracting  Officer  to  determine  whether  there  are  acceptable  terms  for  transferring  such 
rights.  All  noncommercial  computer  software  in  which  the  Contractor  has  granted  the  Gov¬ 
ernment  additional  rights  shall  be  listed  or  described  in  a  license  agreement  made  part  of  the 
contract  (see  paragraph  (b)(4)  of  this  clause).  The  license  shall  enumerate  the  additional  rights 
granted  the  Government. 

(iii)  The  Contractor  acknowledges  that — 
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(A)  Restricted  rights  computer  software  is  authorized  to  be  released  or  disclosed  to 
covered  Government  support  contractors; 

(B)  The  Contractor  will  be  notified  of  such  release  or  disclosure; 

(C)  The  Contractor  (or  the  party  asserting  restrictions,  as  identified  in  the  restricted 
rights  legend)  may  require  each  such  covered  Government  support  contractor  to  enter 
into  a  non-disclosure  agreement  directly  with  the  Contractor  (or  the  party  asserting  re¬ 
strictions)  regarding  the  covered  Government  support  contractor’s  use  of  such  software, 
or  alternatively,  that  the  Contractor  (or  party  asserting  restrictions)  may  waive  in  writing 
the  requirement  for  a  non-disclosure  agreement; 

(D)  Any  such  non-disclosure  agreement  shall  address  the  restrictions  on  the  covered 
Government  support  contractor's  use  of  the  restricted  rights  software  as  set  forth  in  the 
clause  at  252.227-7025,  Limitations  on  the  Use  or  Disclosure  of  Government-Furnished 
Information  Marked  with  Restrictive  Legends,  and  shall  not  include  any  additional 
terms  and  conditions  unless  mutually  agreed  to  by  the  parties  to  the  non-disclosure 
agreement;  and 

(E)  The  Contractor  shall  provide  a  copy  of  any  such  non-disclosure  agreement  or  waiv¬ 
er  to  the  Contracting  Officer,  upon  request.” 

In  addition  to  the  standard  licenses,  DEARS  252.227-7014  Rights  in  Noncommercial  Computer  Soft¬ 
ware  and  Noncommercial  Computer  Software  Documentation  describes  two  additional  licensing  and 
rights  constructs: 

“(4)  Specifically  negotiated  license  rights. 

(i)  The  standard  license  rights  granted  to  the  Government  under  paragraphs  (b)(  1)  through 
(b)(3)  of  this  clause,  including  the  period  during  which  the  Government  shall  have  govern¬ 
ment  purpose  rights  in  computer  software,  may  be  modified  by  mutual  agreement  to  provide 
such  rights  as  the  parties  consider  appropriate  but  shall  not  provide  the  Government  lesser 
rights  in  computer  software  than  are  enumerated  in  paragraph  (a)(14)  of  this  clause  or  lesser 
rights  in  computer  software  documentation  than  are  enumerated  in  paragraph  (a)(  1 3)  of  the 
Rights  in  Technical  Data— Noncommercial  Items  clause  of  this  contract. 

(ii)  Any  rights  so  negotiated  shall  be  identified  in  a  license  agreement  made  part  of  this 
contract. 

(5)  Prior  government  rights.  Computer  software  or  computer  software  documentation  that  will 
be  delivered,  furnished,  or  otherwise  provided  to  the  Government  under  this  contract,  in  which  the 
Government  has  previously  obtained  rights  shall  be  delivered,  furnished,  or  provided  with  the  pre¬ 
existing  rights,  unless — 

(i)  The  parties  have  agreed  otherwise;  or 

(ii)  Any  restrictions  on  the  Government's  rights  to  use,  modify,  reproduce,  release,  perform, 
display,  or  disclose  the  data  have  expired  or  no  longer  apply.” 
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2.4  What  You  Need  in  Addition  to  a  Noncommercial  Computer  Software  License  and 
the  Associated  Rights 

The  primary  subject  of  this  report  concerns  licensing  rights  for  noncommercial  computer  software 
for  systems  or  as  standalone  applications.  However,  the  selection  of  license  rights  and  inclusion  of 
the  appropriate  contract  clauses  in  the  RFP  and  contract  are  not  sufficient  to  execute  the  license 
rights.  It  is  critical  to  obtain  deliverables  that  are  also  necessary  for  implementing  license  rights. 
DoD  policy  states  that  “solicitations  and  contracts  shall .  . .  establish  separate  contract  line  items, 
to  the  extent  practicable,  for  the  computer  software  or  computer  software  documentation  to  be 
delivered  under  a  contract  and  require  offerors  and  contractors  to  price  separately  each  deliverable 
data  item”  [DFARS  272.7203-3(b)  2011], 

The  DFARS  definition  of  computer  software  provides  clues  of  types  of  deliverables  that  could  be 
required.  ‘“Computer  software’  [is]  computer  programs,  source  code,  source  code  listings,  object 
code  listings,  design  details,  algorithms,  processes,  flow  charts,  formulae  and  related  material  that 
would  enable  the  software  to  be  reproduced,  recreated,  or  recompiled.  Computer  software  does 
not  include  computer  data  bases  or  computer  software  documentation”  [DFARS  252.227.7014(a) 
(4)  201 1],  “The  standard  license  in  computer  software  documentation  conveys  unlimited  rights” 
[DFARS  227.7203-5  2011],  Despite  the  numerous  items  included  in  the  definition  of  computer 
software,  this  documentation  is  not  delivered  unless  specified  in  the  contract.  Items  that  a  manag¬ 
er  believes  are  necessary  to  develop,  reproduce,  and  maintain  the  software  across  the  product  life 
cycle  must  be  explicitly  called  out  in  the  Contract  Data  Requirements  List  (CDRL).  Examples  of 
important  CDRLs  for  software  acquisitions  include  (but  are  not  limited  to)  [GSAM  Version  3.0 
2000]: 


•  software  and  interface  requirements  specifications 

•  software  and  interface  design  descriptions 

•  database  descriptions 

•  software  product  specifications 

•  source  code  listings 

•  test  plans/descriptions/reports 

•  software  development  plans 

•  software  programming  manuals 

•  software  users  manuals 

•  software  maintenance  manuals 

•  software  architecture  description 

2.5  Resources  to  Help  You  Understand  Rights  to  Noncommercial  Computer  Soft¬ 
ware 

This  report  cannot  cover  all  of  the  guidance  available  on  licensing  of  noncommercial  computer 
software  or  all  of  the  events  that  might  impact  a  licensing  strategy.  Discussions  should  include  not 
only  the  technical  personnel  who  understand  the  software  aspects  of  the  project,  but  also  a  con¬ 
tracting  officer  and  legal  staff.  These  functional  elements  are  crucial  to  ensuring  that  the  software 
licensing  strategy  meets  contractual,  legal,  and  technical  needs  of  the  government  for  noncom¬ 
mercial  computer  software. 
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Codified  material  includes  the  Federal  Acquisition  Regulation  (FAR),  which  provides  acquisition 
regulations  related  to  noncommercial  computer  software  across  all  government  agencies;  and  the 
DFARS  that  supplements  the  FAR  for  DoD  acquisitions.  The  DFARS  contains  DoD-wide  poli¬ 
cies,  delegations  of  FAR  authorities,  deviations  from  FAR  requirements,  and  policies  and  proce¬ 
dures.  The  DFARS  also  covers  the  DoD-unique  process  for  acquiring  intellectual  property  license 
rights  governing  technical  data  or  computer  software  that  is  developed  or  delivered  under  a  con¬ 
tract.  The  Defense  Acquisition  Guidebook  provides  the  acquisition  workforce  with  discretionary 
best  practices  based  on  multiple  sources,  including  in  the  DoD  Directive  5000.01  and  DoD  In¬ 
struction  5000.02,  US  Code,  Public  Law  provisions,  FAR,  and  DFARS. 
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3  Organizing  Choices  for  Selecting  a  Noncommercial 
Computer  Software  Licensing  Strategy 


DoD  policy  is  to  acquire  only  the  computer  software  and  computer  software  documentation,  and 
the  rights  in  such  software  or  documentation,  necessary  to  satisfy  agency  needs  [DFARS 
227.7203-1  2011], 


Meeting  DoD  agency  needs  for  licensing  rights  to  noncommercial  computer  software  for  systems 
or  as  standalone  applications  requires  an  understanding  of  what  is  different  about  each  license  or 
set  of  rights,  an  understanding  of  the  full  system  life  cycle,  and  the  ability  to  evaluate  and  priorit¬ 
ize  licensing  impacts  based  on  possible  future  scenarios.  Before  attempting  to  make  a  decision  on 
a  particular  licensing  strategy  for  noncommercial  computer  software,  an  acquiring  organization 
needs  to  understand  the  licensing  terms  and  rights  conveyed  to  the  government  and  retained  by 
the  contractors.  The  extent  of  rights  that  each  license  type  conveys  ranges  from  relatively  few  re¬ 
strictions  to  multiple  restrictions. 

At  the  most  basic  level,  four  distinguishing  characteristics — Scope  of  Use,  Access  or  Transfer, 
Commercial  Prospects,  and  Funding  Source — are  prominent  in  differentiating  license  rights  for 
noncommercial  computer  software.  For  those  technical  managers  who  need  to  have  a  starting 
point  in  the  software  licensing  decision  process,  it  is  important  to  understand  these  characteristics 
and  how  these  characteristics  are  treated. 

3.1  Scope  of  Use 

Who  needs  to  use  or  modify  the  product  at  various  times  of  the  life  cycle  and  to  what  extent? 

This  report  uses  Scope  of  Use  to  refer  to  the  extent  to  which  the  software  license  grants  the  gov¬ 
ernment  and/or  its  agent  the  rights  to  modify,  reproduce,  release,  perform,  display,  or  disclose 
noncommercial  computer  software. 

The  three  examples  below  suggest  how  DoD  agencies’  needs  related  to  Scope  of  Use  can  lead  to 
the  selection  of  a  specific  software  license  type. 

1 .  The  DoD  agency  may  need  the  flexibility  to  authorize  multiple  contractors,  including 
those  who  are  competitors  of  the  original  developer,  to  modify  the  software  up  to  and  in¬ 
cluding  developing  derivative  works  across  the  life  cycle.  This  Scope  of  Use  example 
supports  the  selection  of  Unlimited  Rights.  See  Table  1  for  review  of  Unlimited 
Rights/License  related  to  Scope  of  Use. 

2.  The  DoD  agency  may  need  to  plan  for  future  involvement  of  competing  contractors  but 
can  support  near-term  limits  on  that  involvement  in  exchange  for  possible  cost  reduc¬ 
tions.  This  Scope  of  Use  example  supports  the  selection  of  Government  Purpose 
Rights.  See  Table  lfor  review  of  Government  Purpose  Rights/License  related  to  Scope 
of  Use.  Note:  Government  Purpose  Rights  are  negotiated  for  a  mutually  agreed-upon 
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length  (nominally  five  years).  After  the  GPR  period  expires,  the  government  receives 
Unlimited  Rights. 

3.  The  DoD  agency  may  need  the  continuity  of  relying  on  the  contractor  who  has  devel¬ 
oped  a  very  specific  software  product  except  for  activities  to  service  contracts  and  emer¬ 
gency  repairs/overhaul.  This  Scope  of  Use  example  supports  the  selection  of  Restricted 
Rights.  See  Table  1  for  review  of  Restricted  Rights/License  related  to  Scope  of  Use. 

Table  1  displays  the  three  standard  noncommercial  computer  software  license  types  and  the  dif¬ 
ferent  ways  that  rights  related  to  Scope  of  Use  are  treated  under  each  license. 

Table  1:  Treatment  of  Scope  of  Use  by  Licensing  Types 


Distinguishing  Charac¬ 
teristics 

Scope  of  Use 


STANDARD  NONCOMMERCIAL  COMPUTER  SOFTWARE  LICENSE  TYPES 

Unlimited  Rights 

Government  Purpose  Rights 

Restricted  Rights 

DISTINGUISHING  CHARACTERISTIC  OPTIONS  BY  LICENSE  TYPE 

Any  use  for  any  purpose 
by  anyone  the  Govern¬ 
ment  authorizes 

Inside  Government  -  disclosure 
required  if  other  than  contractor  or 
subs  of  the  government  contract 

Outside  Government  for  govern¬ 
ment  purposes  only  -  only  with 
express  written  permission  of  con¬ 
tractor/developer 

Reverts  to  unlimited  rights  after 

GPR  expires 

Permission  to  diagnose,  modify 
or  merge  software;  respond  to 
tactical  situations  and  perform 
emergency  repairs.  Notification 
to  rights  owner  and  no  reverse 
engineering 

3.2  Access  or  Transfer 

What  restrictions  on  access  by  terminals  and  central  processing  units  or  on  transfer  to  other  gov¬ 
ernment  agencies  are  acceptable? 

Access  or  Transfer  refers  to  availability  for  use  within  the  DoD  agency  and  conditions  of  transfers 
to  other  agencies.  Restrictions  on  internal  access  (e.g.,  CPU  installation)  and  on  transfer  to  other 
agencies  (with  or  without  destruction  of  existing  copies)  play  an  important  role  in  the  long-term 
usefulness  of  the  product.  The  need  to  physically  access  the  software  product  and  acceptable 
rules  governing  transfer  to  other  agencies  require  careful  consideration. 

The  three  examples  below  suggest  how  DoD  agency  needs  related  to  Access  or  Transfer  can  lead 
to  the  selection  of  a  specific  software  license  type. 

1 .  The  DoD  agency  may  need  broad  access  to  the  noncommercial  computer  software  via 
multiple  terminals  and  CPUs  and/or  plans  for  concurrent  usage  across  multiple  go¬ 
vernmental  and  nongovernmental  organizations.  This  Access  or  Transfer  example 
supports  the  selection  of  Unlimited  Rights.  See  Table  2  for  review  of  Unlimited 
Rights/License  related  to  Access  or  Transfer. 

2.  The  DoD  agency  may  need  broad  access  via  multiple  terminals  and  CPUs  but  can  lim¬ 
it  transfers  of  the  software  only  within  the  government  for  a  negotiated  period  of  time 
and  still  meet  objectives.  This  Access  or  Transfer  example  supports  the  selection  of 
Government  Purpose  Rights.  See  Table  2  for  review  of  Govermnent  Purpose 
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Rights/License  related  to  Access  or  Transfer.  These  restrictions  last  for  the  negotiated 
Government  Purpose  Rights  period.  Note:  Government  Purpose  Rights  are  negotiated 
for  a  mutually  agreed-upon  length  (nominally  five  years).  After  the  GPR  period  ex¬ 
pires,  the  govermnent  receives  Unlimited  Rights. 

3.  The  DoD  agency  may  need  access  to  no  more  than  one  terminal  or  CPU  at  a  time,  to 
one  government  agency  at  a  time,  and  to  contractors  only  performing  service  contracts 
in  support  of  this  or  a  related  contract.  This  Access  or  Transfer  example  supports  the 
selection  of  Restricted  Rights.  See  Table  2  for  review  of  Restricted  Rights/License  re¬ 
lated  to  Access  or  Transfer. 

Table  2  displays  the  three  standard  noncommercial  computer  software  license  types  and  the  dif¬ 
ferent  ways  that  rights  related  to  Scope  of  Use  and  Access  or  Transfer  are  treated  under  each  li¬ 
cense. 

Table  2:  Treatment  of  Scope  of  Use  and  Access  or  Transfer  by  Licensing  Types 


STANDARD  NONCOMMERCIAL  COMPUTER  SOFTWARE  LICENSE  CHOICES 

Unlimited  Rights 

Government  Purpose  Rights 

Restricted  Rights 

Distinguishing  Charac¬ 
teristics 

DISTINGUISHING  CHARACTERISTIC  OPTIONS  BY  LICENSE  TYPE 

Scope  of  Use 

Any  use  for  any  purpose 
by  anyone  the  Govern¬ 
ment  authorizes 

Inside  Government  -  disclosure 
required  if  other  than  contractor  or 
subs  of  the  government  contract 

Outside  Government  for  govern¬ 
ment  purposes  only  -  only  with 
express  written  permission  of  con¬ 
tractor/developer 

Permission  to  diagnose,  modify 
or  merge  software;  respond  to 
tactical  situations  and  perform 
emergency  repairs.  Notification 
to  rights  owner  and  no  reverse 
engineering 

Reverts  to  unlimited  rights  after 

GPR  expires 

Access  or  Transfer 

Inside  and  Outside  Gov¬ 
ernment  -  No  Limit 

Inside  Government  -  transfer  to 
other  agencies  without  restriction  on 
access;  contractors  and  subs  work¬ 
ing  on  government  contract  can 
access;  reverts  to  unlimited  rights 
after  GPR  expires 

One  agency  at  a  time 

Destroy  copies  when  transferred 
to  another  agency 

3.3  Commercial  Prospects 

Are  there  any  plans  that  the  software  or  system  with  software  will  be  developed  or  used  for 
commercial  purposes? 

Commercial  Prospects  refers  to  plans  by  either  the  government  or  the  developer  to  bring  the  prod¬ 
uct  to  the  commercial  marketplace.  The  govermnent  may  wish  to  commercialize  or  authorize  oth¬ 
ers  to  commercialize  a  noncommercial  computer  software  product.  The  government  may  also  rec¬ 
ognize  that  it  is  in  its  interest  to  allow  the  developer  time  to  commercialize  the  product. 
“Generally,  software  is  commercialized  through  owner  licensing  either  directly  to  end-users  or  to 
an  entity  that  will  further  develop  and  distribute  it  themselves.  In  some  cases,  commercialization 
may  mean  collaborating  with  an  industry  partner  to  improve  the  software  and  make  it  suitable  for 
distribution”  [McMaster  University  2008], 
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The  three  examples  below  suggest  how  DoD  agency  needs  related  to  Commercial  Prospects  can 
lead  to  the  selection  of  a  specific  software  license  type. 

1 .  The  DoD  agency  may  need  to  take  direct  advantage  of  commercializing  the  noncommer¬ 
cial  computer  software  as  soon  as  feasible.  This  Commercial  Prospects  example  supports 
the  selection  of  Unlimited  Rights.  See  Table  3  for  review  of  Unlimited  Rights/License 
related  to  Commercial  Prospects. 

2.  The  DoD  agency  may  need  to  encourage  possible  commercial  benefits  to  support  indus¬ 
try  competition  and  stimulate  bidding  on  a  government  contract  for  a  negotiated  time  pe¬ 
riod.  This  Commercial  Prospects  example  supports  the  selection  of  Government  Purpose 
Rights.  See  Table  3  for  review  of  Government  Purpose  Rights/License  related  to  Com¬ 
mercial  Prospects.  Note:  Government  Purpose  Rights  are  negotiated  for  a  mutually 
agreed-upon  length  (nominally  five  years).  After  the  GPR  period  expires,  the  govern¬ 
ment  receives  Unlimited  Rights. 

3.  The  DoD  agency  may  need  to  agree  that  only  the  developer  will  commercialize  the 
product  with  no  restriction  on  time  period.  This  Commercial  Prospects  example  supports 
the  selection  of  Restricted  Rights.  See  Table  3  for  review  of  Restricted  Rights/License 
related  to  Commercial  Prospects. 

Table  3  displays  the  three  standard  noncommercial  computer  software  license  types  and  the  dif¬ 
ferent  ways  that  rights  related  to  Scope  of  Use,  Access  or  Transfer,  and  Commercial  Prospects  are 
treated  under  each  license. 
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Table  3:  Treatment  of  Scope  of  Use,  Access  or  Transfer,  and  Commercial  Prospects  by  Licensing 
Types 


STANDARD  NONCOMMERCIAL  COMPUTER  SOFTWARE  LICENSE  CHOICES 

Unlimited  Rights 

Government  Purpose  Rights 

Restricted  Rights 

Distinguishing  Charac¬ 
teristics 

DISTINGUISHING  CHARACTERISTIC  OPTIONS  BY  LICENSE  TYPE 

Scope  of  Use 

Any  use  for  any  purpose 
by  anyone  the  Govern¬ 
ment  authorizes 

Inside  Government  -  disclosure 
required  if  other  than  contractor  or 
subs  of  the  government  contract 

Outside  Government  -  only  with 
express  written  permission  of  con¬ 
tractor/developer 

Reverts  to  unlimited  rights  after 

GPR  expires 

Permission  to  diagnose,  modify 
or  merge  software;  respond  to 
tactical  situations  and  perform 
emergency  repairs.  Notification 
to  rights  owner  and  no  reverse 
engineering 

Access  or  Transfer 

Inside  and  Outside  Gov¬ 
ernment  -  No  Limit 

Inside  Government  -  transfer  to 
other  agencies  without  restriction  on 
access;  contractors  and  subs  work¬ 
ing  on  government  contract  can 
access;  reverts  to  unlimited  rights 
after  GPR  expires 

One  agency  at  a  time 

Destroy  copies  when  transferred 
to  another  agency 

Commercial  Prospects 

Government  commer¬ 
cialize  or  authorize  oth¬ 
ers  to  commercialize 

Contractor/developer  commercializ¬ 
es  during  GPR;  reverts  to  unlimited 
rights  after  GPR  expires 

Solely  contractor/developer 

3.4  Funding  Source 

Who  is  going  to  fund  or  has  funded  the  noncommercial  computer  software  development  and 
to  what  extent? 

Funding  Source  refers  to  the  source  of  funds  used  to  develop  the  noncommercial  computer  soft¬ 
ware  either  as  a  standalone  item  or  as  part  of  a  system.  The  three  levels  of  funding  associated  with 
the  standard  noncommercial  computer  software  license  types  are  government  funding  only  (asso¬ 
ciated  with  Unlimited  Rights),  government  funding  mixed  with  contractor  private  expense  (asso¬ 
ciated  with  Government  Purpose  Rights),  and  private  expense  only  (associated  with  Restricted 
Rights).  Specifically  Negotiated  Agreements  allow  modification  by  mutual  agreement  of  available 
rights  when  the  terms  of  other  licensing  rights  are  not  satisfactory.  Flowever,  the  government  can¬ 
not  accept  lesser  rights  than  those  granted  by  Restricted  Rights  [DFARS  252.227-7014  (b)  (4)  (i) 
2011], 

To  ensure  that  the  funding  determination  is  balanced  and  that  both  the  government  and  contractor 
receive  credit  for  funding  contributions,  “the  determination  of  the  source  of  funds  used  to  develop 
computer  software  should  be  made  at  the  lowest  practicable  segregable  portion  of  the  software  or 
documentation  (e.g.,  a  software  sub-routine  that  performs  a  specific  function)”  [DFARS 
227.7203-4  License  Rights  -  (b)  Source  of  funds  determination  2011], 

The  three  examples  below  suggest  how  DoD  agency  needs  related  to  Funding  Source  can  lead  to 
the  selection  of  a  specific  software  license  type. 

1 .  The  DoD  agency  may  need  to  provide  all  of  the  funds  for  the  noncommercial  computer 
software  development.  This  Source  of  Funds  example  supports  the  selection  of  Unli- 
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mited  Rights.  See  Table  4  for  review  of  Unlimited  Rights/License  related  to  Funding 
Source. 

2.  The  DoD  agency  may  need  to  provide  some  funding,  along  with  the  supplier,  who  is  also 
providing  funding  for  the  noncommercial  computer  software  development.  This  Source 
of  Funds  example  supports  the  selection  of  Government  Purpose  Rights.  See  Table  4 
for  review  of  Government  Purpose  Rights/License  related  to  Funding  Source.  Note: 
Govermnent  Purpose  Rights  are  negotiated  for  a  mutually  agreed-upon  length  (nominally 
five  years).  After  the  GPR  period  expires,  the  government  receives  Unlimited  Rights. 

3.  The  DoD  agency  may  need  to  plan  on  the  supplier  providing  all  funding  for  the  non¬ 
commercial  computer  software  development.  This  Source  of  Funds  example  supports  the 
selection  of  Restricted  Rights.  See  Table  4  for  review  of  Restricted  Rights/License  re¬ 
lated  to  Funding  Source. 

Table  4  displays  the  three  standard  noncommercial  computer  software  license  types  and  the  dif¬ 
ferent  ways  that  rights  related  to  Scope  of  Use,  Access  or  Transfer,  Commercial  Prospects,  and 
Funding  Source  are  treated  under  each  license. 

Table  4:  Treatment  of  Scope  of  Use,  Access  or  Transfer,  Commercial  Prospects,  and  Funding  Source 
by  Licensing  Types 


STANDARD  NONCOMMERCIAL  COMPUTER  SOFTWARE  LICENSE  CHOICES 

Unlimited  Rights 

Government  Purpose  Rights 

Restricted  Rights 

Distinguishing  Charac¬ 
teristics 

DISTINGUISHING  CHARACTERISTIC  OPTIONS  BY  LICENSE  TYPE 

Scope  of  Use 

Any  use  for  any  purpose 
by  anyone  the  Govern¬ 
ment  authorizes 

Inside  Government  -  disclosure 
required  if  other  than  contractor  or 
subs  of  the  government  contract 

Outside  Government  -  only  with 
express  written  permission  of  con¬ 
tractor/developer 

Reverts  to  unlimited  rights  after 

GPR  expires 

Permission  to  diagnose,  modify 
or  merge  software;  respond  to 
tactical  situations  and  perform 
emergency  repairs.  Notification 
to  rights  owner  and  no  reverse 
engineering 

Access  or  Transfer 

Inside  and  Outside  Gov¬ 
ernment  -  No  Limit 

Inside  Government  -  transfer  to 
other  agencies  without  restriction  on 
access;  contractors  and  subs  work¬ 
ing  on  government  contract  can 
access;  reverts  to  unlimited  rights 
after  GPR  expires 

One  agency  at  a  time 

Destroy  copies  when  transferred 
to  another  agency 

Commercial  Prospects 

Government  commer¬ 
cialize  or  authorize  oth¬ 
ers  to  commercialize 

Contractor/developer  commercializ¬ 
es  during  GPR;  reverts  to  unlimited 
rights  after  GPR  expires 

Solely  contractor/developer 

Funding  Source 

Solely  Government 
funding 

Mixed  funding 

Private  expense 

3.5  Putting  the  Distinguishing  Characteristics  Together 
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As  illustrated  in  the  previous  sections,  DoD  agency  needs  support  the  eventual  rationale  for  se¬ 
lecting  a  licensing  strategy  for  noncommercial  computer  software.  Table  5  below  shows  the  com¬ 
plete  table  with  all  distinguishing  characteristics  present. 

Table  5:  Treatment  of  Scope  of  Use,  Access  or  Transfer,  Commercial  Prospects,  and  Funding  Source 
by  Licensing  Types 


STANDARD  NONCOMMERCIAL  COMPUTER  SOFTWARE  LICENSE  CHOICES 

Unlimited  Rights 

Government  Purpose  Rights 

Restricted  Rights 

Distinguishing  Charac¬ 
teristics 

DISTINGUISHING  CHARACTERISTIC  OPTIONS  BY  LICENSE  TYPE 

Scope  of  Use 

Any  use  for  any  purpose 
by  anyone  the  Govern¬ 
ment  authorizes 

Inside  Government  -  disclosure 
required  if  other  than  contractor  or 
subs  of  the  government  contract 

Outside  Government  -  only  with 
express  written  permission  of  con¬ 
tractor/developer 

Permission  to  diagnose,  modify 
or  merge  software;  respond  to 
tactical  situations  and  perform 
emergency  repairs.  Notification 
to  rights  owner  and  no  reverse 
engineering 

Reverts  to  unlimited  rights  after 

GPR  expires. 

Access  or  Transfer 

Inside  and  Outside  Gov¬ 
ernment  -  No  Limit 

Inside  Government  -  transfer  to 
other  agencies  without  restriction  on 
access;  contractors  and  subs  work¬ 
ing  on  government  contract  can 
access;  reverts  to  unlimited  rights 
after  GPR  expires. 

One  agency  at  a  time 

Destroy  copies  when  transferred 
to  another  agency 

Commercial  Prospects 

Government  commer¬ 
cialize  or  authorize  oth¬ 
ers  to  commercialize 

Contractor/developer  commercializ¬ 
es  during  GPR;  reverts  to  unlimited 
rights  after  GPR  expires. 

Solely  contractor/developer 

Funding  Source 

Solely  Government 
funding 

Mixed  funding 

Private  expense 

It  is  possible  that  the  government  has  a  clear  understanding  of  its  needs  related  to  a  specific  dis¬ 
tinguishing  characteristic  such  as  Scope  of  Use.  However,  it  is  also  possible  that  the  government 
will  need  to  conduct  a  more  detailed  review  of  product  life  cycle  considerations  to  understand  the 
underlying  needs  that  point  the  government  in  a  certain  direction. 

For  example,  what  future  events  might  occur  that  would  require  the  government  to  need  maxi¬ 
mum  flexibility  in  types  of  work  they  can  authorize  a  competing  contractor  to  do?  Can  a  short¬ 
ened  life  cycle  overcome  concerns  on  dependence  on  the  original  developer  and  restricted  rights? 
What  changes  in  technology  could  make  commercialization  by  the  developer  a  viable  venture? 
The  next  section  suggests  a  structured  approach  to  identify  the  underlying  drivers  for  DoD  agency 
needs  that  point  the  government  in  a  certain  licensing  direction. 
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4  Decision  Drivers  to  Identify  Agency  Noncommercial 

Computer  Software  Licensing  Needs  -  Scope  of  Use  Focus 


Data  managers  or  other  requirements  personnel  are  responsible  for  identifying  the  government's 
minimum  needs  [DFARS  227.7203-2(b)  (1)  2011]. 

Contracting  officers  shall  work  closely  with  data  managers  and  requirements  personnel  to  assure 
that  computer  software  and  computer  software  documentation  requirements  included  in  solicita¬ 
tions  are  consistent  with  the  policy  expressed  in  227.7203-1  [DFARS  227.7203-2(b)  (1)  201 1]. 


DoD  policy  clearly  states  that  its  policy  is  “to  acquire  only  the  computer  software  and  computer 
software  documentation,  and  the  rights  in  such  software  or  documentation,  necessary  to  satisfy 
agency  needs”  [DFARS  227.7203-1  2011],  This  section  suggests  a  systematic  and  objective  ap¬ 
proach  to  identifying  the  government’s  minimum  needs  for  noncommercial  computer  software 
licensing  rights.  The  approach  is  demonstrated  in  this  section  using  the  Scope  of  Use  characteris¬ 
tic  as  a  focus.  The  approach  as  described  for  Scope  of  Use  can  be  equally  applied  to  Access  or 
Transfer,  Commercial  Prospects,  and  Funding  Source. 


Using  this  approach,  data  managers  and  other  requirements  personnel  can  document  the  progres¬ 
sion  from  DoD  agency  programmatic  and  performance  expectations  to  license  strategy  selection. 
The  approach  also  allows  for  forward  and  backward  traceability  from  agency  expectations  to  ul¬ 
timate  selection,  as  well  as  facilitating  revisions  in  the  case  of  change.  The  approach  can  be  used 
as-is,  modified  to  suit  different  program  types  or  circumstances,  or  completely  redefined. 

4.1  Taxonomy  to  Support  Noncommercial  Computer  Software  Licensing  Strategy 
Discussions 

A  systematic  and  objective  approach  to  identifying  DoD  agency  expectations  for  systems  with 
software  can  benefit  from  a  common  set  of  terms  and  discussion  topics  related  to  acquisition  of 
noncommercial  computer  software.  A  review  of  the  literature  did  not  reveal  an  existing  tool  to 
meet  these  requirements.  However,  the  Taxonomy  of  Software  Development  Risks  provides  a 
foundation  tool  with  a  software  orientation  that  can  be  used  to  develop  the  common  set  of  terms 
and  discussion  topics  needed  for  the  licensing  discussion  [Dorofee  et  al  1 996]2.  Appendix  B 
shows  this  original  taxonomy. 

Minor  modification  of  the  Taxonomy  of  Software  Development  Risks  added  key  software  acqui¬ 
sition  topics  to  generate  discussion  of  DoD  agency  expectations.  This  modification  resulted  in  the 
Modified  Taxonomy  for  Software  Acquisition  Life  Cycle  Discussion  in  Table  6.  It  retains  the 
original  classes,  elements,  and  attributes  of  the  Taxonomy  of  Software  Development  Risks,  and 
adds  a  new  class  entitled  Software  Criticality.  This  class  consists  of  Scale,  Reliance,  and  Com¬ 
plexity  elements.  Other  additions  are  3  elements  and  16  attributes  for  Program  Constraints  that 

2  The  Taxonomy  of  Software  Development  Risks  is  based  on  Bloom’s  Taxonomy  of  Learning  Domains. 
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account  for  acquisition-specific  topics,  2  attributes  for  Development  Environment,  and  8 
attributes  for  Product  Engineering.  Additions  to  the  original  taxonomy  are  displayed  in 
UPPERCASE. 


Table  6:  Modified  Taxonomy  for  Software  Acquisition  Life  Cycle  Discussion 


A. 


a. 

b. 

c. 

d. 

e. 

f. 

9- 

h. 

i. 

j- 


a. 

b. 

c. 

d. 

e. 

f. 
9- 


3. 

a. 

b. 

c. 


a. 

b. 

c. 

d. 

e. 


a. 

b. 

c. 

d. 

e. 

f. 
9- 

h. 

i. 


Product 

Engineering 


Requirements 


B. 


1. 


Stability 

Completeness 

Clarity 

Validity 

Feasibility 

Precedent 

Scale 


VERIFIABILITY 
INTEROPERABILITY  2 
TECHNICAL 
MATURITY 


Design 

Functionality 

Difficulty 

Interfaces 

Performance 

Testability 

Hardware  constraints 

Non-developmental 

software 


Code  and  Unit  Test 
Feasibility 
Testing 
Cod¬ 
ing/implementation 

Integration  and  Test 
Environment 
Product 
System 

CERTIFICATIONS 
SYSTEM  OF 
SYSTEMS 


Engineering  Specialties 
Maintainability 
Reliability 
Safety 
Security 
Human  Factors 
Specifications 
SUSTAINMENT 
AVAILABILITY 
DEPLOYMENT 


a. 

b. 

c. 

d. 

e. 

f. 
9- 


a. 

b. 

c. 

d. 

e. 

f. 
9- 


a. 

b. 

c. 

d. 


a. 

b. 

c. 

d. 


a. 

b. 

c. 

d. 


Development 

Environment 


C. 


Development  1. 


Process  a. 


COMPLIANCE  b. 

OWNERSHIP  c. 


Suitability 
Process  control 
Familiarity 
Product  control 
Measurement 

Development 

System 


d. 

a. 

b. 

c. 

d. 


Capacity 

Suitability 

Usability 

Familiarity 

Reliability 

System  support 

Deliverability 

Management 

Process 
Planning 
Project  Organi¬ 
zation 

Management 
Experience 
Program  Inter¬ 
faces 


e. 

f. 

a. 

b. 

c. 

d. 

e. 

f. 
9- 


a. 


b. 


Management  c 

Methods 
Monitoring 

Personnel  d. 

Management 
Quality  Assur-  g 
ance 

Configuration  f 

Management 

Work  Environ-  c. 

ment 

Quality  attitude  d. 

Cooperation 
Communication 
Morale 


a. 

b. 


c. 

d. 

e. 


Program  Constraints 


D. 


Resources 


1. 


Schedule 

Staff 

Budget 

Facilities 

Contract 
Type  of  contract 
Restrictions 
Dependencies 
ACQUISITION 
STRATEGY 
SOLICITATION 
SOFTWARE  LICENSING 


b. 


2. 


a. 


b. 


3. 


Program  Interfaces 
Customer 

Associate  Contractors 

Subcontractors 

Prime  contractor 

Corporate  Management 

Vendor 

Politics 


PROGRAM  OFFICE 

CAPABILITY 

SOFTWARE  EXPERTISE 

PROGRAM  AND  PROJECT 

MANAGEMENT 

EXPERTISE 

UNDERSTANDING  OF 

ACQUISITION 

RESPONSIBILITIES 

MONITORING 

PROCESSES 


CHAIN  OF  COMMAND 
CONSISTENCY 
LEVEL  OF 
COMMUNICATIONS 
FEASIBILITY  OF 
EXPECTATIONS 
ALLOCATION  OF 
RESPONSIBILITY 


POLICY  AND 
MANDATES 

EXTERNAL  CONSTRAINTS 
POLITICAL  CONSTRAINTS 
THREAT  MITIGATION 
TECHNOLOGIES 
MULTIPLE  GUIDELINES 
AND  PRACTICES 


Software 

Criticality 


SCALE 

SOFTWARE 

AS 

PROPORTION 
OF  SYSTEM 
IMPACT  ON 
MAJOR 
SOFTWARE 
COMPONENT 

RELIANCE 

MISSION 

SYSTEM 

COMPLEXITY 

SPECIFIC 

SYSTEM 

COMMUNITY 

OF 

INTERACTING 

SYSTEMS 
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4.2  From  Expectations  to  a  Needs-Based  Noncommercial  Computer  Software  Li¬ 
censing  Strategy 

The  suggested  process  begins  not  by  picking  a  licensing  strategy  and  then  justifying  it.  Rather,  it 
begins  by  determining  DoD  agency  expectations  for  noncommercial  systems  with  software  or  as 
standalone  applications.  These  expectations  could  be  operational,  programmatic,  budgetary,  or 
technical.  The  Modified  Taxonomy  for  Software  Acquisition  Life  Cycle  Discussion  can  serve  as  a 
prompt  for  determining  all  of  the  areas  where  DoD  agency  expectations  might  be  present.  These 
expectations  could  relate  to  what  the  DoD  agency  expects  to  gain,  how  the  DoD  agency  expects  to 
support  the  mission,  expected  events  across  the  life  cycle,  etc. 

Using  Scope  of  Use  as  the  focus,  this  section  will  use  the  following  steps  to  illustrate  the  progres¬ 
sion  from  DoD  agency  expectations  to  DoD  agency  needs  for  noncommercial  computer  software 
license  rights: 

1 .  Identify  DoD  agency  expectations  that  cover  the  whole  life  cycle  for  the  systems  with 
software. 

2.  Construct  one  or  more  high-level  statements  that  describe  the  DoD  agency’s  plan  to  meet 
each  expectation. 

3.  Identify  and  prioritize  the  necessary  software-related  capabilities  that  the  DoD  agency 
must  have  to  be  successful  with  its  plan.  These  capabilities  will  become  decision  drivers. 

4.  Select  all  software  license  types  that  support  each  decision  driver  (capability)  and  deter¬ 
mine  the  best  overall  option  by  reviewing  the  priorities  of  the  decision  drivers  and  the  li¬ 
cense  types  that  most  often  satisfy  the  decision  drivers. 

The  intent  of  the  following  notional  examples  is  to  show  various  expectations  that  could  inform 
the  needs  of  an  agency.  The  examples  do  not  represent  any  particular  program  nor  are  they  exam¬ 
ples  from  existing  programs.  Rather,  they  are  individual  topics  suggested  in  the  Modified  Tax¬ 
onomy  of  Software  Acquisition  Life  Cycle  Discussion  and  were  selected  to  generate  discussion 
about  expectations,  plans,  and  capabilities.  The  purpose  is  to  show  how  to  arrive  at  a  meaningful 
decision  driver  to  select  the  appropriate  noncommercial  computer  software  license.  The  weights 
assigned  to  decision  drivers  in  these  examples  are  notional  and  do  not  represent  either  a  particular 
program  or  set  of  circumstances.  Results  for  each  example  are  notional.  It  is  also  important  to 
note  that  expectations,  plans,  capabilities,  and  priorities  may  change  as  discussions  evolve. 

Notional  Example  1:  Software  Criticality  -  Reliance 

Expectation:  The  DoD  agency  expects  fulltime  availability  of  the  system  and  software  be¬ 
cause  the  mission  is  highly  reliant  on  the  software. 

Plan:  The  DoD  agency  will  plan  for  24x7  uptime  in  operations  and  availability  during  the  life 

of  the  system,  regardless  of  force  location  in  the  world. 

Capability/Decision  Drivers:  To  support  the  plan,  the  government  must  have  these  capabili¬ 
ties: 


•  access  to  all  code,  tools,  test  scripts,  etc.  to  repair  defects 

•  legal  rights  to  perform  any  necessary  work  or  authorize  others  to  do  it 
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•  authority  to  engage  competing  contractors,  if  necessary,  to  perform  work,  including 
creating  derivative  works 

•  qualified  talent  available  during  life  cycle  that  knows  how  to  work  with  the  software 
Priority  Assigned:  High  Priority 

Notional  Example  2:  Program  Constraints  -  Contract 

Expectation:  The  contractor  who  is  awarded  the  contract  can  do  the  work  and  is  financially 
sound. 

Plan:  The  government  will  ensure  access  to  software  product  regardless  of  contractor  status. 
Capability/Decision  Drivers:  To  support  the  plan,  the  government  must  have: 

•  ability  to  allow  newly  hired  contractor  to  perform  work  on  software  if  contractor  fails 
in  performance 

•  ability  to  re-compete  without  losing  progress  to  date  if  original  contractor  goes  out  of 
business 

•  access  to  source  code  such  as  through  escrow  regardless  of  contractor  status 
Priority  Assigned:  Medium  Priority 

Notional  Example  3:  Product  Engineering  -  Design 

Expectation:  Many  of  the  software  components  will  be  candidates  for  future  reuse. 

Plan:  The  government  must  ensure  the  ability  to  reuse  software  components  in  any  fashion 
required  by  the  system. 

Capability/Decision  Drivers:  To  support  the  plan,  the  government  must  have: 

•  ability  to  modify  software  in  any  manner  to  support  new  functionality 

•  rights  that  will  allow  maximum  flexibility  in  changes  as  software  is  reused 

•  capability  to  change  across  product  life  of  decades 

Priority  Assigned:  Medium  Priority 

Notional  Example  4:  Product  Engineering  -  Integration  and  Test 

Expectation:  Integral  to  the  system  design  will  be  integration  with  other  systems. 

Plan:  The  government  must  ensure  that  all  conditions  for  software  changes  to  support  inte¬ 
gration  can  be  met  in  a  timely  manner. 

Capability/Decision  Drivers:  To  support  the  plan,  the  government  must  have: 

•  ability  to  obtain  support  to  modify  software  at  any  point  in  the  life  cycle  to  ensure  in¬ 
tegration 

•  authority  to  change  software  as  other  systems  are  integrated  within  SOS 
Priority  Assigned:  High  Priority 
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Notional  Example  5:  Product  Engineering  -  Engineering  Specialties 

Expectation:  The  government  expects  to  sustain  the  software  with  internal  resources. 

Plan:  The  government  will  allocate  sufficient  resources  to  perform  all  aspects  of  sustainment 
of  the  system  until  disposal. 

Capability/Decision  Drivers:  To  support  the  plan,  the  government  must  have: 

•  ability  to  correct,  adapt,  and  enhance  software  years  after  delivery 

•  internal  tools  and  talent  to  perform  required  work 

Priority  Assigned:  High  Priority 

Table  7  is  a  work  aid  to  show  how  one  might  display  the  expectations,  plan,  capability/decision 
drivers,  and  the  results  by  license  type  that  can  support  the  licensing  selections.  It  is  important  to 
remember  that  Contracting  Officers  and  Legal  can  provide  the  best  advice  on  the  appropriate  se¬ 
lections. 

When  reviewing  the  results,  note  that  placing  an  X  in  every  cell  in  a  row  means  that  the  decision 
driver  can  be  satisfied  by  any  license.  Likewise,  where  no  row  in  a  given  example  contains  an  X, 
further  review  will  be  necessary  to  determine  if  the  DoD  agency  expectation  or  plan  is  feasible. 
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Table  7;  Display  of  Expectations,  Plans,  and  Decision  Drivers 


NOTIONAL  DISPLAY  OF  EXPECTATIONS,  PLANS,  AND  DECISION  DRIVERS 
MAPPED  TO  NONCOMMERCIAL  COMPUTER  SOFTWARE  LICENSE  RIGHTS 


Government  Pur¬ 
pose  Rights 

Restricted 

Rights 

^Unlimited 

Rights 

DOD  AGENCY  NEED  FOR  SCOPE  OF  USE 

RIGHTS  OBTAINED  FOR  I - 

SCOPE  OF  USE 

J>Any  use  for  any 
purpose  by  any¬ 
one  that  the  Gov¬ 
ernment  authoriz¬ 
es 

Inside  Government  - 
disclosure  required  if 
other  than  contractor 
or  subs  of  the  gov¬ 
ernment  contract 

Outside  Government 
-  only  with  written 
permission 

Only  permission 
to  diagnose, 
modify  or  merge 
software;  re¬ 
spond  to  tactical 
situations  and 
perform  emer¬ 
gency  repairs 

NOTIONAL  EXAMPLE  1 


High 

Priority 

RELIANCE  EXPECTATION:  The  DoD  agency  expects  fulltime  availability  of  the  system  and  software 
because  the  mission  is  highly  reliant  on  the  software. 

High 

Priority 

RELIANCE  PLAN:  The  DoD  agencv  will  plan  for  24x7  uptime  in  operations  and  availability  during  the  life  of 
the  system,  regardless  of  force  location  in  the  world. 

Criticality  -  access  to  all  code, 
tools,  test  scripts,  etc 

X 

X 

cc 

LU 

=!  Q 

CO 

Criticality  -  legal  rights  to  perform 
any  necessary  work  or  authorize 
others  to  do  it 

X 

(after  GPR  period) 

to 

<  CD 

LU 

Q 

Criticality  -  authorize  competing 
contractor  to  modify  work,  includ¬ 
ing  creating  derivative  works 

X 

(after  GPR  period) 

Criticality  -  qualified  talent  available 
during  the  entire  life  cycle 

X 

X 

X 

NOTIONAL  EXAMPLE  2 


Medium 

Priority 

CONTRACT  EXPECTATION:  The  contractor  awarded  the  contract  will  be  capable  and  financially  sound. 

Medium 

Priority 

CONTRACT  PLAN:  The  government  will  ensure  access  to  software  product  regardless  of  contractor  status. 

CAPABILITY/ 

DECISION 

DRIVERS 

Contract  -  ability  to  allow  newly 
hired  contractor  to  perform  work  on 
software  if  contractor  fails  to  per¬ 
form 

X 

X 

Contract  -  ability  to  re-compete 
without  losing  progress  to  date  if 
original  contractor  goes  out  of 
business 

X 

(after  GPR  period) 
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NOTIONAL  DISPLAY  OF  EXPECTATIONS,  PLANS,  AND  DECISION  DRIVERS 
MAPPED  TO  NONCOMMERCIAL  COMPUTER  SOFTWARE  LICENSE  RIGHTS 


STANDARD  LICENSE  TYPES  i - 

>Unlimited 

Rights 

Government  Pur¬ 
pose  Rights 

Restricted 

Rights 

DOD  AGENCY  NEED  FOR  SCOPE  OF  USE 

RIGHTS  OBTAINED  FOR  I - 

SCOPE  OF  USE 

[>Any  use  for  any 
purpose  by  any¬ 
one  that  the  Gov¬ 
ernment  authoriz¬ 
es 

Inside  Government  - 
disclosure  required  if 
other  than  contractor 
or  subs  of  the  gov¬ 
ernment  contract 

Outside  Government 
-  only  with  written 
permission 

Only  permission 
to  diagnose, 
modify  or  merge 
software;  re¬ 
spond  to  tactical 
situations  and 
perform  emer¬ 
gency  repairs 

NOTIONAL  EXAMPLE  3 


Medium 

Priority 

DESIGN  EXPECTATION:  Manv  of  the  software  components  will  be  candidates  for  future  reuse. 

Medium 

Priority 

DESIGN  PLAN:  The  government  must  be  able  to  reuse  components  in  any  fashion  required  by  the  system. 

CAPABILITY/ 

DECISION 

DRIVERS 

Design  -  ability  to  modify  software 
in  any  manner  to  support  new 
design 

X 

(after  GPR  period) 

X 

Design  -  rights  that  will  allow  max¬ 
imum  flexibility  in  changes  as  soft¬ 
ware  is  reused 

X 

(after  GPR  period) 

Design  -  capability  to  change 
across  product  life  of  decades 

X 

(after  GPR  period) 

X 

NOTIONAL  EXAMPLE  4 


High 

Priority 

INTEGRATION/TEST  EXPECTATION:  Inteeral  to  the  system  design  will  be  integration  with  other  svs- 
terns. 

High 

Priority 

INTEGRATION/TEST  PLAN:  The  government  must  ensure  that  all  conditions  for  software  changes  to  sun- 
port  integration  can  be  made  in  a  timely  manner. 

bm 

m  O  cr 

Integration/Test  -  ability  to  obtain 
support  to  modify  software  at  any 
point  in  the  life  cycle  to  ensure 
integration 

X 

(after  GPR  period) 

CL  LU  CC 
<  Q  Q 

Integration/Test  -  authority  to 
change  software  as  other  systems 
change  within  SOS 

X 

X 

NOTIONAL  EXAMPLE  5 


High 

Priority 

ENGINEERING  SPECIALITIES  EXPECTATION:  The  government  expects  to  sustain  the  software  with 
internal  resources. 

High 

Priority 

ENGINEERING  SPECIALITIES  PLAN:  The  government  will  allocate  sufficient  resources  to  perform  all 
aspects  of  sustainment  of  the  system  until  disposal. 

□  O  cr 

==  F7i  LU 

Operations  -  ability  to  correct, 
adapt,  and  enhance  software  years 
after  delivery 

X 

X 

CO  _  ■> 

£  LU  S 
<QQ 

Operations  -  tools  and  talent  to 
perform  required  work  over  several 
years 

X 

X 

X 

If  there  is  no  agreement  between  the  government  and  the  developer  on  a  standard  license,  or  the 
government  wants  to  obtain  rights  in  noncommercial  computer  software  in  which  it  does  not  have 
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rights,  the  parties  can  agree  to  a  Specifically  Negotiated  License.  Described  in  the  DFARS  as  an 
unusual  situation  [DFARS  227.7203-5],  the  major  limitations  of  this  type  of  license  are  that  the 
govermnent  cannot  accept  less  than  restricted  rights,  and  the  intellectual  property  owner  is  not 
required  to  give  more  than  restricted  rights. 
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5  Other  Considerations 


Other  considerations  that  are  addressed  by  the  DFARS  that  can  affect  noncommercial  licensing 
rights  strategies  generally  relate  to  specific  entities  and/or  circumstances  that  a  technical  manager 
may  encounter  in  the  course  of  running  the  project.  This  section  provides  a  high-level  description 
of  these  considerations  and  references  to  their  coverage  in  DFARS.  These  considerations  relate  to 
and  include: 

•  subcontractor  rights  in  computer  software 

•  disclosure  or  release  to  foreign  governments,  foreign  contractors,  or  international  organi¬ 
zations 

•  contracts  under  the  Small  Business  Innovative  Research  Program 

•  contracts  for  special  works 

Subcontractor  rights  for  software  they  developed.  Subcontractors  receive  the  same  protection 
for  their  rights  to  computer  software  as  the  prime  contractor  receives.  The  government  can  deal 
directly  with  subcontractors  in  matters  related  to  validation  of  asserted  restrictions.  In  addition, 
prime  contractors  must  include  specified  clauses  such  as  Rights  in  Noncommercial  Computer 
Software  and  Noncommercial  Computer  Software  Documentation  in  subcontractor  contracts 
without  modification  [DFARS  252.227.7014  2011],  Lastly,  the  prime  contractor  cannot  require 
the  subcontractor  to  relinquish  rights  greater  than  those  obtained  by  the  government  in  the  prime’s 
contract  [DFARS  227.7203-15  2011], 

Disclosure  or  release  to  foreign  governments,  foreign  contractors,  or  international  organizations. 
Disclosure  or  release  to  these  entities  is  subject  to  Federal  export  controls  and  other  national  secu¬ 
rity  laws  or  regulations.  If  these  laws  and  regulations  are  met,  DoD  can  release  computer  software 
if  it  holds  unlimited  rights.  If  a  license  includes  restrictions,  DoD  must  observe  the  requirements 
for  use  and  non-disclosure  agreements  [DFARS  227.7203-16  2011], 

Contracts  under  the  Small  Business  Innovative  Research  (SBIR)  Program.  The  contractor  must 
mark  the  computer  software  with  an  SBIR  data  rights  legend.  The  government  receives  rights  for 
government  purposes  for  a  period  beginning  at  award  and  ending  five  years  after  completion  of 
the  project.  After  the  period  expires,  the  government  receives  unlimited  rights  to  SBIR  data 
[DFARS  227.7104  2011], 

Contracts  for  special  works.  Per  Rights  in  Special  Works  [DFARS  252.227-7020  2011],  the  gov¬ 
ernment  may  have  a  specific  need  to  control  noncommercial  computer  software  distribution.  One 
method  of  controlling  distribution  is  to  obtain  assignment  of  the  copyright.  The  specific  software 
or  documentation  in  which  the  govermnent  must  own  or  control  copyright  must  be  identified  in  a 
special  contract  requirement.  If  the  government  needs  control  of  all  of  the  computer  software,  it 
will  use  DFARS  252.227-7020  exclusively.  The  contractor  retains  use  and  disclosure  rights 
[DFARS  227.7205  2011], 
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6  Conclusion 


The  information  in  this  report  illustrates  the  tremendous  responsibility  that  falls  to  data  managers 
and  other  requirements  personnel  at  the  beginning  of  an  acquisition — a  time  when  there  are  major 
decisions  in  multiple  areas.  Evolving  a  licensing  strategy  for  noncommercial  computer  software 
requires: 

•  awareness  of  the  rules  of  software  ownership 

•  an  understanding  of  the  program’s  current  status  and  future  possibilities 

•  the  ability  to  distinguish  among  the  types  of  noncommercial  computer  software  licenses 
available  in  the  DoD  environment 

•  insight  into  the  choices  that  each  of  those  licenses  represents 

•  the  ability  to  fonnulate  a  rationale  for  DoD  agency  needs,  based  on  in-depth  knowledge 
and  an  understanding  of  acquisition  and  the  life  cycle 

If  the  noncommercial  computer  software  licensing  strategy  is  flawed,  consequences  that  will  ap¬ 
pear  later  in  the  product  life  cycle  can  be  additional  costs,  schedule  delays  due  to  legal  issues,  and 
risks  to  continued  operation.  DoD  managers,  contracting  officers,  and  legal  staff  who  apply  a 
structured  approach  can  evolve  a  well-supported  decision  for  licensing  needs  of  noncommercial 
computer  software  development. 
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Appendix  A  -  Selected  DFARS  Definitions3  4 


Commercial  computer  software:  software  developed  or  regularly  used  for  non-govemmental 
purposes  which 

i.  has  been  sold,  leased,  or  licensed  to  the  public; 

ii.  has  been  offered  for  sale,  lease,  or  license  to  the  public; 

iii.  has  not  been  offered,  sold,  leased,  or  licensed  to  the  public  but  will  be  available  for  com¬ 
mercial  sale,  lease,  or  license  in  time  to  satisfy  the  delivery  requirements  of  this  contract; 
or 

iv.  satisfies  a  criterion  expressed  in  paragraph  (a)  (1)  (i),  (ii),  or  (iii)  of  this  clause  and  would 
require  only  minor  modification  to  meet  the  requirements  of  this  contract  [DFARS 
252.227-7014  (a)  (1)2011]. 

Computer  program:  a  set  of  instructions,  rales,  or  routines,  recorded  in  a  form  that  is  capable  of 
causing  a  computer  to  perform  a  specific  operation  or  series  of  operations  [DFARS  252.227-7014 
(a)  (3)2011], 

Computer  software:  computer  programs,  source  code,  source  code  listings,  object  code  listings, 
design  details,  algorithms,  processes,  flow  charts,  formulae,  and  related  material  that  would  ena¬ 
ble  the  software  to  be  reproduced,  recreated,  or  recompiled.  Computer  software  does  not  include 
computer  databases  or  computer  software  documentation  [DFARS  Subpart  252.227-7014  (a)  (4) 
2011], 

Computer  software  documentation:  owner’s  manuals,  user’s  manuals,  installation  instructions, 
operating  instructions,  and  other  similar  items,  regardless  of  storage  medium,  that  explain  the  ca¬ 
pabilities  of  the  computer  software  or  provide  instructions  for  using  the  software  [DFARS  Subpart 
252.227-7014  (a)(5)  2011], 

Data:  recorded  information,  regardless  of  form  or  the  media  on  which  it  may  be  recorded.  The 
term  includes  technical  data  and  computer  software.  The  term  does  not  include  information  inci¬ 
dental  to  contract  administration,  such  as  financial,  administrative,  cost  or  pricing,  or  management 
information  [FAR  Subpart  27.401,  FAR  52.227-12010]. 

Developed:  means  that  (i)  a  computer  program  has  been  successfully  operated  in  a  computer  and 
tested  to  the  extent  sufficient  to  demonstrate  to  reasonable  persons  skilled  in  the  art  that  the  pro¬ 
gram  can  reasonably  be  expected  to  perform  its  intended  purpose;  (ii)  computer  software,  other 
than  computer  programs,  has  been  tested  or  analyzed  to  the  extent  sufficient  to  demonstrate  to 
reasonable  persons  skilled  in  the  art  that  the  software  can  reasonably  be  expected  to  perform  its 
intended  purpose;  or  (iii)  computer  software  documentation  required  to  be  delivered  under  a  con- 


3 

Defense  Federal  Acquisition  Regulation  Supplement  (DFARS)  227. 72— Rights  in  Computer  Software  and  Computer  Software 
Documentation.  Revised  20  January  2011. 

4  Code  of  Federal  Regulations  (CFR),  Title  48— Federal  Acquisition  Regulations  System.  Chapter  1— Federal  Acquisition  Regula¬ 
tion  (FAR).  Revised  as  of  October  1,  2010. 
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tract  has  been  written,  in  any  medium,  in  sufficient  detail  to  comply  with  requirements  under  that 
contract  [DFARS  Subpart  252.227-7014  (a)(7)  2011], 

Government  purpose:  any  activity  in  which  the  United  States  Government  is  a  party,  including 
cooperative  agreements  with  international  or  multi-national  defense  organizations,  sales,  or  trans¬ 
fers  by  the  United  States  Government  to  foreign  governments  or  international  organizations.  Gov¬ 
ernment  purposes  include  competitive  procurement,  but  do  not  include  the  rights  to  use,  modify, 
reproduce,  release,  perform,  display,  or  disclose  computer  software  or  computer  software  docu¬ 
mentation  for  commercial  purposes  or  authorize  others  to  do  so  [DFARS  252.227-7014  (a)(  1 1) 
2011], 

Noncommercial  computer  software:  software  that  does  not  qualify  as  commercial  computer 
software  under  paragraph  (a)  (1)  of  DFARS  252.227-7014  [DFARS  252.227-7014  (a)  (14)  2011], 

Technical  data:  data  other  than  computer  software,  which  are  of  a  scientific  or  technical  nature 
[FAR  Subpart  27.401  —  Definitions  2010], 


3 

Defense  Federal  Acquisition  Regulation  Supplement  (DFARS)  227. 72— Rights  in  Computer  Software  and  Computer  Software 
Documentation.  Revised  20  January  2011. 

4 

Code  of  Federal  Regulations  (CFR),  Title  48— Federal  Acquisition  Regulations  System.  Chapter  1— Federal  Acquisition  Regu¬ 
lation  (FAR).  Revised  as  of  October  1,  2010. 


CMU/SEI-2011-TR-014  |  29 


Appendix  B  -  Taxonomy  of  Software  Development  Risks5 


Taxonomy-Based  Questionnaire 
(TBQ) 


Description  The  taxonomy-based  questionnaire  (TBQ)  consists  of  questions,  along  with  specific  cues 

and  follow-up  probe  questions,  under  each  attribute  in  the  Software  Development  Risk 
Taxonomy. 


Class 


Element 


Attribute 


Taxonomy  of  Software  Development  Risks 

►A.  Product  Engineering  B. 

Development  Environment 

C.  Program  Constraints 

1. 

Requirements 

1. 

Development  Process 

1. 

Resources 

a.  Stability 

a.  Formality 

a.  Schedule 

b.  Completeness 

b.  Suitability 

b.  Staff 

c.  Clarity 

c.  Process  Control 

c.  Budget 

d.  Validity 

d.  Familiarity 

d.  Facilities 

e.  Feasibility 

e.  Product  Control 

2. 

Contract 

f.  Precedent 

2. 

Development  System 

a.  Type  of  Contract 

g.  Scale 

a.  Capacity 

b.  Restrictions 

►  2. 

Design 

b.  Suitability 

c.  Dependencies 

a.  Functionality 

c.  Usability 

3. 

Program  Interfaces 

b.  Difficulty 

d.  Familiarity 

a.  Customer 

c.  Interfaces 

e.  Reliability 

b.  Associate 

d.  Performance 

f.  System  Support 

Contractors 

e.  Testability 

g.  Deliverability 

c.  Subcontractors 

f.  Hardware 

3. 

Management  Process 

d.  Prime 

Constraints 

a.  Planning 

Contractor 

g.  Non- 

b.  Project  Organization 

e.  Corporate 

Developmental 

c.  Management 

Management 

Software 

Experience 

f.  Vendors 

3. 

Code  and  Unit  Test 

d.  Program  Interfaces 

g.  Politics 

a.  Feasibility 

4. 

Management  Methods 

b.  Testing 

a.  Monitoring 

c.  Coding/lmple- 

b.  Personnel 

mentation 

Management 

4. 

Integration  and  Test 

c.  Quality  Assurance 

a.  Environment 

d.  Configuration 

b.  Product 

Management 

c.  System 

5. 

Work  Environment 

5. 

Engineering 

a.  Quality  Attitude 

Specialties 

b.  Cooperation 

a.  Maintainability 

c.  Communication 

b.  Reliability 

d.  Morale 

c.  Safety 

d.  Security 

e.  Human  Factors 

f.  Specifications 

Dorofee,  A.  J.,  Walker,  J.  A.,  Alberts,  C.  J.,  Higuera,  R.  P.,  Murphy,  R.  L.,  and  Williams,  R.  C.  Continuous  Risk  Management 
Guidebook.  Software  Engineering  Institute,  Carnegie  Mellon  University,  1996. 
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